Expert GeoServer: Build and secure advanced interfaces and interactive maps by Ben Mearns

Author:Ben Mearns [Mearns, Ben]
Language: eng
Format: epub
Publisher: Packt Publishing
Published: 2018-07-30T23:00:00+00:00

If the resource allocation is too high, it will cause an out-of-memory error and GeoServer will crash. If we set our parameters too low, although this may result in greater stability on the server, it can cause requests to drop or slow down.

The easiest way to alter the JVM settings shown in the preceding screenshot is to alter the JAVA_OPTS environment variable. In the following screenshot, you can see an echo of the JAVA_OPTS environment variable:

These may be some of the settings that we already set. By default, you probably won't see anything when you echo the environment variable. There are, however, some parameters. One is related to the minimum amount of memory (Xms128m) used by GeoServer or the JVM when you start them up. We can bump this up to add memory so that GeoServer isn't trying to allocate this as it runs into higher demand for resources. We can also set a maximum amount of memory (Xmx756M) that the JVM can grab, which can prevent an out-of-memory error. The SoftRefPolicy parameter is related to the amount of memory that we give to the reference, which is related to the cache. If we bump it up, we'll have more information stored in the cache, which of course enhances performance. The downside, however, is that we might run into an out-of-memory error again if it takes up too much memory in the cache.

The command in Windows for setting environment variables is setx. The following is an example of how to add a new parameter to the JAVA_OPTS environment variable. The UseParNewGC parameter involves garbage collection:

C:\Users\mearns>setx JAVA_OPTS "%JAVA_OPTS% --XX:+UseParNewGC"

There are a number of garbage collection options that you can use with the JVM. This one in particular involves multiple threads for doing garbage collection, concurrent with other requests that may be going on in your GeoServer instance. The benefit here is that GeoServer doesn't need to pause to carry out this action, and garbage collection of course frees up memory.

The control flow extension limits the number of concurrent operations, such as requests and threads. Control flow offers a similar kind of tuning challenge; hiring a resource allocation such as concurrent requests to provide greater memory will give us an out-of-memory crash, but too little memory will result in greater latency.

In addition to the usual extension installation process, the control flow extension requires a manually created controlflow.properties file under the data_dir directory. The content for this can be found on the control flow reference page on the GeoServer site (http://docs.geoserver.org/stable/en/user/extensions/controlflow/index.html), or you can use the sample that we've provided with the book:

# if a request waits in queue for more than 60 seconds it's not worth executing,

# the client will likely have given up by then

timeout=60

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.